AFO 300 – Serials module - introduction
300.1 Components of the serials module
The Serials administration module has four components:
· the registration for the receipt of single issues;
· a claim mechanism;
·
a routing module;
· a binding administration.
The financial administration does not take place in the serials administration, but via the Acquisitions module, which contains an extensive budget management option and various specific options for the financial management of serials and loose-leaf works. For example, the system has a number of specific ‘order types' such as ‘periodical' and ‘series'.
Recording the receipt of single issues
With receipt registration for single issues you can record incoming issues in the system. In order to make this as efficient as possible, the system predicts the issues expected. General data regarding the subscription must be defined for this, which allows the system to predict the expected issues in the correct manner. This prediction can take place both on an individual basis and for all subscriptions simultaneously. It is also possible to receive issues the system has not predicted.
Claim mechanism
A list of expected issues is created based on the prediction algorithm, so that the prediction process can run quickly. However, if predicted issues are not received, the claim mechanism starts. The system makes a distinction between ‘issues not received' and ‘stagnated subscriptions'. In the first case, we are dealing with individual issues that have not yet come in; in the latter case with subscriptions for which no issues after a specific issue have been received. It is also possible to specify the periods at which claims are sent yourself. The lay-out of the claims is defined in the SSP module. The claims mechanism is a process that takes place in three steps allowing you to manage claims that the system automatically traces so that you, rather than the system, determine whether a claim is sent.
Routing module
The routing module enables you to define routing lists and to print them. The system supports both line and star routing and a mixture of the two types.
The bibliographic data for serials is entered in the bibliographic file; thus there is no separate serials file. This means that subscriptions can be linked to descriptions that have already been entered. All search methods for identifying descriptions are also available in the serials administration module.
Serials management is linked to the SSP module. Subscription data can play a role in selecting, sorting and printing. In addition, the SSP print module is used when printing claims, routing lists, etc.
Binding administration
It is possible to create bound sets of (barcoded) issues belonging to a particular volume. See section 300.6 for more information.
Please note
If your system uses cataloguing permissions, it is possible the message below appears in case you are not permitted to add, modify or delete subscriptions, or receive them.
See the relevant help section of AFO 651 for more information.
300.2 Subscriptions
The central data element within serials management is ‘the subscription'. Each subscription is linked to a bibliographic description, which means that multiple subscriptions may be linked to one bibliographic description, but also that one subscription is linked to multiple descriptions (if a serial changes its name and this results in the entry of a new description).
Three types of information can be linked to each subscription:
· general data regarding the subscription such as the frequency and the prediction pattern;
· information about single issues, primarily the receipt and/or prediction data for each issue;
· routing data, such as the routing list members, which issues have already been circulated, etc.
Each subscription is characterised by a unique subscription number in the system. Subscription numbers can be entered manually or can be automatically assigned by the system. Subscription numbers may be a maximum of twenty-five characters (digits and/or letters) long and may not consist exclusively of punctuation marks.
You can search for a subscription number on the system number tab of the standard search screen. For serial publications, using an acronym can also be a handy search method.
300.3 Link with the acquisitions module
The system enables you to establish a link from the serials module to acquisitions. The purpose of this link is to allow you to enter financial information (e.g. budget information) about the serials from the single serial numbers receipt screen. The system allows you to enter data for a single issue which will automatically update the price, budget, invoice and budget year in acquisitions.
This is a one-way link: the registration of the receipt of an issue in acquisitions has absolutely no implication for that issue's receipt status in serials management. Because the financial registration does not have to correspond with the receipt registration in serials management (an invoice can come in earlier or later than the issues being invoiced), this means that a separate action must be performed for receipt registration in serials management.
To be able to work with this link, the following conditions must be met:
· The acquisitions and serials management modules must both be operational in the system.
· The subscription data must include an order number in the ‘Order Number' field. The order entered here must be linked to the same bibliographic description to which the subscription is linked.
· The ‘Current' field must indicate that the link must be activated for the subscription in question.
300.4 Routing
300.4.1 The routing process
The routing process that can be managed by the system actually consists of three phases:
· Routing recognition at receipt. When a single issue is received (in AFO 311) the system checks whether the serials title has a routing list attached. If so, the system indicates this and the routing process is started automatically.
· Printing of routing slips. After you have received one or more issues that must be routed, you can (for example once a day) request that the system create a output file with routing slips. The system then collects all the routing slips for the day in question and you can print them, if desired.
· Return receipt of after routing. The third phase we are about to discuss is optional. You can set the system parameters in such a way that that no receipt registration is performed. This means that for the system the routing ends after phase two. However, you can also opt to perform a receipt registration: when a routed issue is returned to the library, this is recorded.
We call the participants in the routing process routing list members. These routing list members are included in a list, the routing list, for a routed subscription. This list specifies the sequence in which single issues circulate. After a single issue is received for a routed subscription, the system automatically creates a output file with routing slips. The routing slip contains one or more routing list members. This slip is then sent along with the routed issue. Routing begins when the library sends the serial to the first routing list member and ends the moment that issue is returned to the library.
The system distinguishes three types of routing:
· line routing : a ‘single' issue leaves the library to go to a list of routing list members and is only returned to the library after the last routing list member on the list has read that issue;
· star routing: a ‘single' issue leaves the library to go to the first routing list member, returns to the library, leaves to go to the second routing list member, is again returned to the library, etc.;
· mixed routing: a mixed form of line and star routing.
Routing has a number of general characteristics.
The module is integrated with the other modules (the cataloguing module, serials administration and borrower administration).For example: subscriptions can be identified using all the search methods available to the cataloguers; an issue's routing is automatically initialised upon receipt of the issue in serials administration.
Routing list members are taken from the borrower file, which functions as a central, personal data file (with the considerable advantage that mutations only have to be entered at one place).
The module is equipped with many parameters, so that each institution can modify the module to suit its own needs. In addition, the most important parameters can be modified interactively. The most important parameters are:
· is the serial routed (yes or no);
· the default when entering a new subscription (routing: yes or no);
· the type of routing (line, star or mixed);
· the default type (line, star or mixed);
· the default routing period (or is this a number of days, or a category);
· the maximum number of routing list members per line (however, this can be unlimited);
· is receipt registration performed;
· the type of claim mechanism (no claims, claims only in case of star routing, claims only in case of line routing, always send claims).
Each institution can specify whether it wishes to send claims if routed issues are not returned on time. The periods and texts for claims are variable and can be modified.
Before you can circulate single issues of a subscription, the following activities must be performed :
· In AFO 361 you must set the general parameter ‘Circulate' to Y (yes).
· For the subscription you must set the field ‘Circulate' to Y (yes).
· In AFO 362 you must define the lay-out of the routing slips.
300.4.2 Routing lists
A routing list can be created per subscription. Borrowers can be placed on the routing list by selecting by name or by borrower number. A routing type (line, star or ‘new line') and routing period are linked to each borrower. The period is expressed in the number of days the borrower may keep the issue, but can also be entered as a category (for example ‘permanent').
The number of ‘lines' within a routing list is unlimited just as is the number of routing list members per line. Of course it is also possible that multiple subscriptions of the same serial may be routed simultaneously.
After borrowers are placed on a routing list, the following standard changes can be made:
· delete a borrower from the routing list;
· delete all borrowers from the routing list (in one action);
· change the location of borrowers;
· add new borrowers;
· mark a borrower to be deleted from the routing list;
· modify the type of routing (line, star or ‘new line') and the ‘routing period' for a borrower.
In addition, you can copy routing lists from one subscription to another.
Per borrower, you can display an online survey of all the subscriptions on whose routing list he/she appears. In addition, from this survey you can:
· switch to routing list management (so that you have access to all the routing lists on which this borrower appears from a central place);
· delete the borrower from all the routing lists (in one action);
· mark the borrower as ‘temporarily out of routing';
· mark the borrower as ‘definitively out of routing'.
Printing routing slips is a process that takes place via AFO 344. In this AFO you can request the system to collect the routing slips for a specific day. The system then collects all the letters for subscriptions for which a single issue was received that day (in AFO 311) or for which a routing transaction was initiated in routing transaction control (AFO 341). (If an issue is received that must continue routing).
The output file that contains all the routing slips can be modified up to just before the time it is printed, that is to say routing slips can be deleted from the output file, the sequence of the routing list members on a list can be changed (once) (including deleting and/or adding new borrowers), etc.
The texts and the lay-out for the routing slips are variable and can be modified interactively.
300.4.3 Circulation transactions
Generally a routing transaction starts the moment the receipt of a single issue is recorded in AFO 311. However, if you want to start a routing process without an issue being received, you can do this via AFO 341 (‘Routing transactions control'). This AFO allows you to route a single issue or to initialise a new routing process separate from the receipt registration.
Each institution can decide for itself whether it also wishes to perform receipt registration.
If there is no receipt registration, the library performs no more actions in this system after initiating routing (the issue leaving the library / printing the routing lists) . This means you cannot check the progress of the routing, no claims are created, etc.). This option only makes sense if routing always consists of only one line. In practice, this option is less suitable for other types of routing.
If receipt registration is performed, the library registers not only the initiation of routing (the issue leaving the library / printing the routing slips), but it also records the return of the issue after it has been circulated. This option is used for star routing and for mixed star/line routing.
Transaction control handles these processes and includes various types of registrations:
· Automatic processing: When a routed serials issue is returned the system either displays the message ‘routing terminated', or ‘routing continued'. In the latter case, the system automatically selects the following routing list member(s) from the routing list (unless they are specified as ‘temporarily or definitively out of routing', until the maximum number of routing list members per line is exceeded, etc.).
· Manual processing: This means the library employees themselves can determine to whom the issue must be routed. On the one hand the option includes automatic routing, but on the other it also provides the option of adding borrowers to the routing list once or of compiling a one-time (unique) routing list. In other words, it is possible to route an issue to borrowers X-B-C-A-Z-Y while the subscription routing list only contains borrowers A-B-C-D-E.
· Stopping the routing: Routing can be stopped any time an issue is returned.
· Initialising a routing process: It is possible to start a routing process (again, for example for an issue that must be routed further, for an issue for which the routing has been interrupted, etc.).
· Survey of the routed issues: Finally, transaction control offers a total survey of all the issues for a subscription that are routed. The following elements can be viewed per routed issue:
- the borrowers that are included in the routing (incl. the dates they must have the serial in their possession if the routing is completed according to plan);
- when the issue left the library;
- when the issue should arrive back in the library;
- have claims been sent (if so, on what dates);
- a remark about the routing.
300.5 Printing
The serials administration contains a refined print process. In this paragraph we will only discuss the standard print options for claims.
300.5.1 Print profiles
The system distinguishes eighteen types of claims. An SSP print profile can be defined per claim type, which makes it possible to vary the contents and the lay-out of the various types of claims.
The print profiles that can be defined are linked to three types of data:
· the type of subscription (paid subscriptions, free subscriptions or memberships);
· the sequence number for the claim (first, second or third claim);
· the reason the claim should be sent (missing issues, stagnant subscriptions).
In total, this provides eighteen different profiles. Within AFO 351, 352 and 353, the system shows an overview of the various types of output files.
Creating and sending claims is a three-phase process, which will be explained in detail below. Before you can send claims (in AFO 321) you must link an claim period to each subscription for which you wish to create claims and you must define the requisite print profiles (in AFO 363).
If the system detects that a predicted issue has not been received, the single issue will be included in a ‘temporary' output file. The system distinguishes between claims for ‘missing issues' and for ‘stagnant subscriptions'.
Missing issues are issues for which the predicted date has been exceeded by the number of days defined for the subscription. Initially the system only creates claims for missing issues. However, if the system detects that multiple consecutive issues are missing, it will change the ‘claim status' (the claim type) from ‘missing issues' to ‘stagnant subscription'. The system parameters are set at installation in such a way that the status ‘stagnant subscription' is only created after a third claim has been reached for an issue in a series of three consecutive issues that have not been received (and for which the due date has expired).
The distinction between these two types of claims is created to make two items possible:
· the possibility to differentiate between claims in terms of text and lay-out;
· the possibility to send the claims to different addresses (suppliers). (This makes it possible to send the claims for missing issues to a distributor and those for stagnant subscriptions to the publisher).
A maximum of three claims can be sent.
300.5.2 Print process
Printing the output file is a three-step process:
·
Phase 1: Create a temporary output file.
- The system searches through the entire serials file and selects all the issues that satisfy specific criteria specified by the system and places these items in a temporary output file.
·
Phase 2: View the temporary output file and create the definitive output file.
- In the second phase, you can view the issues included in the temporary output file. This enables you to prevent reminders from being included in the definitive output file. Once you have examined the reminders, the temporary output file must be ‘approved', after which the system creates the definitive output file.
·
Phase 3 : Print the definitive output file.
- In the last phase, the definitive output file is printed.
Statuses in the print process
The following statuses can be assigned to each type of output file during the print process:
|
Status |
Description |
Remark |
|
1. |
Being created |
The system is creating a temporary output file |
|
2. |
Building interrupted |
The creation of the temporary output file has been interrupted |
|
3. |
Building finished |
The creation of the temporary output file has been completed. |
|
4. |
Printing |
The system prints the final output file. |
|
5. |
Printing interrupted |
The printing of the final output file has been interrupted. |
|
6. |
Printing finished |
The printing of the final output file has been completed. |
.
The statuses play an important role in the transition from temporary to final output files.
A temporary output file may always be created, even if the previous temporary output file has not been converted to a final output file and also if the previous final output file has not yet been printed. The new issues are added to the temporary output file (a cumulative file is created).
A temporary output file may only be converted to a definitive output file if the previous final output file has been printed completely (that is, the status is 6). The system does not permit a new final output file to be created if the previous one has not been printed. A final output file is thus never cumulative. For example, it is impossible to send claims for complimentary subscriptions if the previous set of claims for this type of output file have not been sent.
A final output file can be printed an unlimited number of times. There is absolutely no restriction on the number of reprints for a final file.
300.6 Binding
While some libraries will bind issues into logical volumes, other libraries will choose to discard issues after several years, due to lack of space for storage. Sometimes the discarded issues are replaced with a microform or online version. Libraries must be able to indicate when they want to bind or discard issues and how many issues will be treated in this manner.
The system offers functionality to automatically alert the staff when it is time to send received issues out to the bindery. Since the binding frequency of titles can be different, each subscription can have a ‘number of issues to bind' and a ‘delay factor' defined. A delay factor accommodates libraries that do not want to be prompted for binding until the first issue of the next binding unit is received. i.e. you receive 5 issues and then the system tells you to bind the previous 4 issues together.
Issues that are bound are kept together in a binding unit. The system keeps a history of all of the binding units created for each subscription. The library is not required to send issues to the bindery as soon as the binding alert is produced. It is possible to delay sending binding units to the bindery until specific times of the year or until budget requirements are met.
During the serials receiving process, you can be alerted to the need to bind by both a message and a printed binding alert. The binding alert contains the issues that should be bound together. After physically locating the issues that are to be bound together, they can be sent out to the bindery, optionally accompanied by a printed binding slip.